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A s part of its effort to hide some of the mundane details of how Windows works from devel- 
opers, Microsoft has actually hidden a few too many facts. One of the issues you need to 
know about is how Windows uses and processes messages. For that matter, you need to know 
how to create your own messages at times. While the built-in message handling provided by 
Microsoft for the .NET Framework environment works most of the time, there are a few situ- 
ations where you might want to have more control than the environment provides. 

This chapter discusses all of the aspects of Windows message processing, handling, and 
generation. You’ll learn about the message pump and some of the other low-level details that 
the .NET Framework normally hides. In addition, we’ll look at some of the messages that the 
.NET Framework handles for you. For example, you have access to the WM_HELP message — 
it’s just hidden by a form event handler (more on this topic in the “Windows Message Handlers 
Found in the .NET Framework” section of the chapter). 

The important bit of information to get from this chapter is that Windows uses a messaging 
system to communicate with applications that’s remained essentially unchanged from the days 
of Windows 3.x. The applications can also communicate with Windows and other applications 
using messages. In short, understanding the messaging system is essential if you want to build 
robust applications. 

Understanding the Windows Message Types 

Windows is literally packed with messages. There are thousands of messages to which your 
application can respond. Even the user interface messages number over a thousand. There 
are messages for mouse movement, keyboard clicks, system messages, user messages, all kinds 
of messages. One of the best places to view these messages in action is Spy++. Figure 4.1 shows 
the Messages tab of the Message Options dialog box. As you can see, there are a number of 
ways to group just the messages that appear in the user interface portion of Windows. (You can 
learn more about Spy++ in the “Spy++” section of Chapter 4 — messages appear in the “Viewing 
Messages” subsection.) 

User interface messages don’t exist in a vacuum — you aren’t going to find many messages 
that exist in isolation. Consider the simple act of clicking a button. When a user clicks the 
button, it generates a WM_LBUTTONDOWN message, and then a WM_LBUTTONUP message. If the user 
presses and releases the mouse button within the time limits of a click, the act also generates 
a BN_CLICKED message, which Windows sends to the button’s parent. This action generates a 
BM_CLICK message, which is where event handlers normally act on the button click (both 
managed and unmanaged). 

However, the presence of a WM_LBUTTONDOWN message doesn’t necessarily signify a button 
click — it also occurs for radio button selections and other control events, so Windows has to 
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know which control is the focus of the action. In addition, the WM_LBUTTONDOWN message can 
begin a drag-and-drop action. The user might not want to actually select the item; they may 
simply want to move it. (Of course, dragging and dropping one or more objects normally 
entails some form of selection — it may simply mean the object isn’t activated.) 


FIGURE 4.1: 

Spy++ provides one 
of the best ways to 
graphically see the 
effects of messages. 



Something I haven’t covered in all of this is the appearance of ancillary messages when a 
user performs most tasks. For example, looking at the same button click from the previous 
paragraph, the user doesn’t just click a button; the mouse cursor has to appear in the right 
place to perform the click. This means generating a wealth of WM_M0USEM0VE messages as the 
user moves the mouse to the correct position in the dialog box. If the user moves the mouse 
outside the dialog area, then the dialog will also receive a WM_MOUSELEAVE message. There’s no 
WM_MOUSEENTER message because the WM_M0USEM0VE message serves to tell the application of 
the mouse entry into the dialog area. 

Fortunately, even in unmanaged applications, a developer only has to track the messages of 
interest and can ignore everything else. The developer doesn’t have to track every message 
and suffer the repercussions of message overload. The .NET Framework further reduces the 
need to track messages — as we’ll see in the “Windows Message Handlers Found in the .NET 
Framework” section that follows. 

In many cases, a user interface message doesn’t affect the user interface directly — it acts in 
the background as a notification of change. For example, Windows issues the WM_SYSCOLOR- 
CHANGE message to all top-level windows whenever the user changes the system colors. This 
notification helps the application maintain the appearance of controls and data so that the 
reader can still see the screen, no matter how garish the color selection. 

There’s a group of messages that affect the application as a whole, including the user interface, 
but act in the background instead of the foreground. For example, Windows issues a WM_POWER 
message every time the machine is about to enter the suspended mode. An application can 
track the WM_P0WER message to determine when the system is about to suspend operations. It 
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can use this message as a way to determine when to save application status information or 
open data files. 

System-level messages often provide two-way communication for applications. An applica- 
tion can receive a system-level notification such as the WM_POWER message. It can also issue a 
system-level request using the WM_SYSCOMMAND message. In this last case, the command often 
has nothing to do with the user interface of an application at all, but does affect system or 
individual application operation. In many cases, the request is for background services that 
the operating system can provide anonymously in an asynchronous fashion. 

If you haven’t noticed already, all of the messages we’ve discussed have a two-letter identi- 
fier followed by the message function, task, or type. The two-letter identifier provides the 
best means of classifying most (but not all) messages. Table 4.1 provides a list of the most 
common message types with accompanying short description. 


Table 4.1 doesn’t contain a complete list of all prefixes. It includes a list of common pre- 
fixes that the developer is likely to use or care about. For example, the list doesn’t con- 
tain the NM prefix because these messages are normally used at a low level for parent 
control notification of events handled at a higher level by application code. 


TABLE 4.1: Common Prefixes for Win32 API Messages 

Prefix Description 

BCM A button control message that changes the resource usage or other inner workings of a button 
or a button-like control. 

BCN A button control notification that notifies the control of a change in status. 

BM A button message that obtains status information about the button or its appearance. This is a 
general prefix used for all button-like controls. 

BN A button notification that specifies a change in the button status, such as a user click. This is a 

general prefix used for all button-like controls. 

CB A control box specific status, resource, or setup message. Note that these entries tend to be 

unique and you'll need to watch button and edit box messages as well. 

CBEM An extended control box specific status, resource, or setup message. 

CDM A common dialog box message that obtains status information about the dialog box or its 
appearance. 

CDN A common dialog box message that specifies a change in dialog box status, such as the user 
clicking the OK button. 

DBT A device specific message generally used to signal a device status change, such as a 
configuration change or when a user plugs in a new device. 

DTM A date/time picker message that obtains status information about the control or its 
appearance. 


Continued on next page 
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TABLE 4.1 CONTINUED: Common Prefixes for Win32 API Messages 

Prefix Description 

DTN A date/time picker message that specifies a change in control status, such as a change in the 
date or time format. 

EM An edit box message that obtains status information about the edit box or its appearance. This 
is a general prefix used for all edit box-like controls. 

EN An edit box notification that specifies a change in the edit box status, such as a change in the 

text content. This is a general prefix used for all edit box-like controls. 

LB A list box specific status, resource, or setup message. 

LBN A list box message that specifies a change in list box status, such as the user double-clicking 

an item. These items tend to be very specialized, so you’ll need to watch standard button 
messages (BN) as well. Depending on the configuration of the list box, you’ll want to consider 
the EN and CB messages as well. 

LBS A list box message that specifies a change in the list box style, such as a change in the 
technique used to sort list box entries. 

LVM A list view message that obtains status information about the control or its appearance. 

LVN A list view message that specifies a change in control status, such as an item change or 

selection. 

LVS A list view message that specifies a change in the list view style, such as a change in the 

technique used to sort list view entries. The styles are a lot more comprehensive than those 
used for LBS messages. For example, there are separate styles for sorting in ascending and 
descending order. 

MM A multimedia message — usually hardware or media specific. For example, this group includes 
messages that affect the joystick. It also includes messages that denote multimedia events 
such as opening a waveform file. 

SC A system control message such as a request to turn on the screensaver or shut the 

system down. 

TB A toolbar specific status, resource, or setup message. 

TBM A trackbar specific status, resource, or setup message. 

TVM A tree-view specific status, resource, or setup message. 

UDM An up-down control specific status, resource, or setup message. 

WM A generic Windows message used for a variety of purposes including system requests. In 
some cases, the message will contain service information. For example, you’ll find a series 
of WM_ADS messages that reflect changes in Active Directory Service status. 


Notice that most of these message categories are user interface specific. That’s because many 
of the messages that Windows handles are user-generated — a user does something and gener- 
ates a message as a result. In addition, some controls have specific status and notification classes 
(such as BM and BN) while others don’t (such as CB). Windows will often classify a control as 
having button-like behavior. It uses the button-related messages to handle user events and pro- 
grammatic changes to those controls. 
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Applications can also create messages, and you’ll find custom messages for certain classes 
of applications. For example, many database managers (DBMSs) use the DB message prefix 
to signal database events such as a new record. In many cases, such as the DB example, you’ll 
find common application messages documented in the Platform SDK help (but not in the 
Visual Studio .NET help). 

A few Win32 API messages are application specific and you’ll generally need to consider 
them only when using Visual C++ (some can be helpful in other situations). For example, the 
DT prefix is used for text drawing messages. Most of these messages do appear in the Visual 
Studio .NET documentation because the current version of Visual C++ .NET uses them. 

Windows Message Handlers Found in the .NET Framework 

The previous section might leave you feeling hopelessly mired in messages you don’t know 
about and aren’t sure that you want to know about. However, we’ll see as the book progresses 
that you need to know about messages because that’s the only form of communication Win- 
dows actually recognizes. In addition, Spy++ can be the most valuable tool in your Win32 
API toolbox. However, you don’t need to memorize all of these messages and you’ll find that 
you don’t have to worry about every message that Windows can process. You’ll find that the 
.NET Framework implements the most common messages for you as event handlers. For 
example, the Cl i ck() event handler is a response to the BN_CLICKED notification. The Spy++ 
display in Figure 4.2 shows the messages generated for the ShowMessage application from 
Chapter 3 when you click the Test button. 


FIGURE 4.2: 

Spy++ can provide 
clues on which 
messages you need 
to implement. 



As you can see, the parent window receives a message that the user has clicked the left button 
(WM_PARENTNOTIFY with the WM_LBUTTONDOWN message as data). This message is passed to the 
child window (a button, in this case), which registers the WM_LBUTTONDOWN message and takes 
control of the message stream. The button also sets its state to true. The user releases the left 
mouse button, which generates a WM_LBUTTONUP message and the requisite setting changes for 
the button. This set of events ends a BN_CLICKED event (not shown). 
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The same messages occur no matter what type of application you create — managed or 
unmanaged. Figure 4.3 shows an example of a simple unmanaged Visual C++ application 
(located in the \Chapte r 04\SayHel 1 o folder of the CD). The MFC application has a few 
additional bells and whistles, such as the selection of a default button, but otherwise the 
message sequence is the same. 


FIGURE 4.3: 

Managed and 
unmanaged 
applications both 
generate the same 
sequence of 
messages. 


Microsoft Spy++ - [Messages (Window 003D01 2C)] 

ED® 

IrjxT Spy Messages Search View Window Help 

- s *1 

!□%(•> if 

<00001 > 002004CA S .BM SETSTYLE dwStyle:BS DEFPUSHBUTTON I BS TEXT 1 0000 1 0000 1 0000 fRedraw:True 

/V 

<00002> 002004CA R .BM~SETSTYLE 

<00003> 002004CA P WM LBUTTONDOWN fwKeys:MK LBUTTON xPos:41 yPos:13 
<00004> 002004CA S BM SETSTATE fS tale: True 
<00005> 002004CA R BM SETSTATE 

<00006> 002004CA P WM LBUTTONUP fwKeys:0000 xPos:41 yPos:13 
<00007> 002004CA S BM SETSTATE IState:False 
<00008> 002004CA R BM SETSTATE 

<00009> 002004CA S ...BM SETSTYLE dwStyle:BS PUSHBUTTON I BS TEXT 1 0000 1 0000 1 0000 fRedraw:True 
<0001 0> 0020Q4CA Fi BMjTTST YLE 


For Help, press FI 

NUM 


Sometimes it’s difficult to correlate a .NET Framework event handler with a Win32 API 
message. In fact, you might not know whether the .NET Framework even provides support 
for a given message. In many cases, you can create a test application that uses what you 
suspect is a Win32 API message, and then see if Spy++ reports that the message is 
active in the test application. If the message isn’t active, then you’ve at least eliminated 
some of the .NET Framework functionality that could support the message. Because 
Microsoft hasn’t provided any documentation that shows the correlation between .NET 
Framework event handlers and Win32 API messages, you'll occasionally need to perform 
this type of interactive research — making Spy++ one of your best friends. 

As previously mentioned, Microsoft hasn’t created a list that shows the correlation between 
Win32 API messages and the event handlers found in the .NET Framework, so you need to 
test as you go along. However, in general, you can count on the .NET Framework handling 
all general control messages, as well as many system-related messages. For example, you’ll 
find that the .NET Framework handles all of the button messages you’ll ever need, so there 
shouldn’t ever be a need to implement a message handler for a button. The same holds true 
for edit and list boxes. 

The .NET Framework doesn’t handle some system messages such as turning the screensaver 
on or off, or changing the display settings. The .NET Framework doesn’t implement any of 
the Windows XP-specific messages. For example, you won’t find any support for the Fast User 
Switching feature. All of these messages will require some type of application support. 

You’ll also find a lack of low-level device support in the .NET Framework. For example, 
general printer commands are handled, but anything going to the parallel port (such as LPT1) 
isn’t. Newer devices such as USB (Universal Serial Bus) drives are handled by the operating 
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system for the most part and you can access the data they contain using standard .NET file 
handling calls. However, if you need to access the drive itself, you’ll need to create special 
message handlers (as well as a wealth of other device handling code). 

An Overview of Windows Message Functions 

Windows messages don’t suddenly jump out of your application and appear in a message queue 
somewhere. You need to generate the messages you want to send to another application using a 
function such as SendMessage(). To receive a message, your application must provide some 
type of listening mechanism, which is going to be an event in most cases. The application will 
need to override the standard .NET message pump to generate the event and provide an event 
handler to perform some task based on the event. 

This section of the chapter discusses some of the Win32 API message functions you’ll use 
to send and receive Windows messages. It’s important to note that sending messages requires 
a complete Win32 API call setup, while receiving messages requires hooks into the existing 
.NET Framework classes. In short, the information below is a starting point — it’s the Win32 
API portion of the picture. We’ll look at how all of the pieces fit within the .NET Framework 
in the various examples in this chapter. 


You might also want to look at the Screensaver example in Chapter 3, which demon- 
strates the simplest way to send a message to Windows that results in a system action. 

The examples in this chapter are a little more complex, so the Chapter 3 example is a 
good place to start. 

SendMessage() 

SendMessageO is the simplest function you can use to send messages to Windows or to 
other applications. One of the best ways to test this function is to work with the system 
commands. You’ll find a complete test program for the system commands in the \Chapter 04\ 
C#\SysCommand and \Chapter 04\VB\SysCommand folders of the CD. This example shows the 
full set of SC commands in action (at least those that are documented). Figure 4.4 shows the 
dialog for this example, which includes a list of the SC commands, along with one long string 
for testing the vertical scroll command (SC_VSCROLL). 


Some commands in the list will only work if you trigger the Test button with the Enter 
key, instead of clicking Test with the mouse. The reason is that the action takes place 
immediately — the mouse cursor changes to the double-pointed or other arrow type. Unfor- 
tunately, because the mouse is already in use, the command fails. The only way to get 
around this problem fortesting is to use the keyboard in place of the mouse. 
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FIGURE 4.4: 


B1 System Command Demonstration | - |fn~|| X 


The SysCommand 
example shows how 
the various system 
commands work. 


Select a command: 


Quit 


SC_MOVE 
SC_MINIMIZE 
SC_MAXIMIZE 
SC_NEXTWINDOW 
SC_PREVWINDOW 
SC_CL0SE 
SC.VSCROLL 
SC_HSCROLL 
SCMOUSEMENU 
SC KEYMENU 
SC_AR RANGE 
SC RESTORE 
SC TASKLIST 
SC_SCREENSAVE 
SC_H0TKEY 
SC.DEFAULT 
SC.MONITORPOWER 
SC_CONTEXTHELP 
SC_SEPARATOR 


Test | 
Default | 


Some of the system commands require special handling. For example, the SC_MONITORPOWER 
command requires input in the 1 Par am argument. The standard value of 0 doesn’t accomplish 
anything. If you input 1, then the display will go to a low power state, while a value of 2 turns 
the display off. The example uses a value of 2 to ensure that most systems will see at least a 
momentary power down of the screen. In some cases, you might have to modify the display 
settings to get this system command to work properly. Here’s the modified code. 

DoSysCommand = (Int32)SystemCommand . SC_M0NIT0RP0WER; 

SendMessage(this. Handle, WM_SYSCOMMAND , DoSysCommand, 2); 

return ; 

Notice that we’re still using the handle for the main window. Figure 4.5 shows another view 
from Spy++. Notice that each of the major controls in the application is also a window. The 
window-like quality of the controls enables you to access them by sending them messages. Of 
course, the control has to have some means of responding to the messages — there’s no magic 
involved. 


FIGURE 4.5: 

Every visible control 
in an application is 
very likely a window 
as well. 


^ Microsoft Spy++ - [Processes 1] 

EBB' 

1 Spy Tree Search View Window Help 

- 3 X| 


n % e> g f* 44 eg El 


- % 

B" 


ffi <6> 

For Help, press FI NUM 


Process 000000E4 SYSCOMMAND 
0 Thread 00000274 SYSCOMMAND 
0 Thread 00000G04 SYSCOMMAND 
0 Thread 000007F4 SYSCOMMAND 

Window 00030456 ".NET -BroadcastE ventWindow.1 .0.3300.0.1 " .NET -BroadcastE ventWindow.1 .0.3300.0.1 
l~l Window 00030458 "System Command Demonstration" WindowsFormsIO. Window. 8. appl 
|-| Window 0003045A "Select a command:" WindowsFormsI 0. ST AT 1C. appl 

□ Window 0003045C "" WindowsFormsI O.LISTBOX.appI 

□ Window 0003045E "Test" WindowsFormsI O.BUTTON.appI 

□ Window 00030460 "Quit" WindowsFormsI O.BUTTON.appI 

: n Window 00030462 "GDI+ Window" GDI+ Hook Window Class 

Process 00000180 DEXPLORE 
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WARNING Figure 4.5 also shows two hidden windows — those with a grayed outline. The first is 
for .NET broadcasts, while the second is for GDI+, as opposed to the plain GDI used by 
standard Windows applications. In most cases, you won’t want to modify these windows 
or send messages to them — you might see unpredictable results. 

To send a message to a control, you need to provide both a handle for the control’s window 
and an event handler to listen for the message. In some cases, such as moving a window, the 
.NET Framework provides a default handler. You can also add your own handler that CLR 
will call when the .NET portion of the call completes. The following code shows how to 
obtain the handle for 1 bCommandSel and use it to move the list box around. 

IntPtr Temp = IntPtr.Zero; // A temporary handle. 

// Load the proper system command. 

DoSysCommand = (Int32)SystemCommand.SC_MOVE; 

// Obtain the handle to the list box. 

Temp = 1 bCommandSel .Handle; 

// Move the list box instead of the main window. 

SendMessage(Temp, WM_SYSCOMMAND , DoSysCommand, 0); 
return ; 

You must highlight the SC_MOVE (List Box) entry in the list, tab twice to highlight the Test 
button, and then press Enter. Clicking Test will cause the code to fail because the mouse is 
already engaged in clicking. You’ll see the mouse cursor change to a quad-ended move cursor. 
Moving the mouse will move the list box. Press Enter again and you’ll see the ending message 
found in the 1 bCommandSel_Move() method. Normally, you’d place any code required to end 
the move command in this method, but the example uses a simple message box. 

PostMessage(), PostThreadMessage, and PostQuitMessage() 

The PostMessageO and the SendMessageO functions perform essentially the same task — 
they both send a message to the specified thread. However, the PostMessageO function 
returns from the call immediately, while the SendMessageO function waits for the recipient 
to respond. Both functions accept essentially the same arguments, so anything you can do 
with a SendMessageO call, you can do with a PostMessageO call. 

You might wonder why Microsoft would include two calls with essentially the same func- 
tionality. There’s a distinct disadvantage when using the PostMessageO call — you don’t know 
if anyone received the message. It’s best to use PostMessageO when you don’t care if anyone 
receives or acts upon the call. 
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There are a number of superceded message functions that you’ll still find in the Platform 
SDK help and in the C/C++ header files. Never use these functions within an application 
because Microsoft doesn’t support them and you don’t know if they'll work in future 
versions of Windows. For example, the PostAppMessageO function has been replaced by 
the PostThreadMessageO function. Unfortunately, examples of these old functions 
prevail online and you even see them in the help files. Refer to the “Obsolete Windows 
Programming Elements” topic in the Platform SDK help file for a list of old functions and 
their replacements. This list isn’t complete, but it’s good place to start. 

Both the PostMessageO and SendMessageO functions can accept special handles. However, 
one of these special handles works better with PostMessageO because it doesn’t incur the delay 
that using SendMessageO would incur. You can use the HWND_BROADCAST handle to tell Windows 
to send a particular message to every accessible window. For example, you might use such a 
call to restore all of the windows as shown in Listing 4. 1 . (The example code appears in the 
\Chapter 04\C#\Mi nimi zeAl 1 and\Chapter 04\VB\Mi nimizeAll folders of the CD.) 


Listing 4.1 


Using the HWND_BROADCAST Handle to Call All Windows 


// Used to send a system command message. 

[D1 f Import ( " User32 . DLL " )] 

public static extern int PostMessageflntPtr hWnd, 

UInt32 Msg, 
Int32 wParam, 
Int32 IParam); 


// The WM_SYSCOMMAND constant used to access the SC constants, 
public const Int32 WM_SYSCOMMAND = 0x112; 

// The HWND_BROADCAST handle sends the message to all windows, 
public IntPtr HWND_BROADCAST = new IntPtr(OxFFFF) ; 


// A list of SC constants used for 
// command access, 
public enum SystemCommand 


SC_SIZE 

SC_M0VE 

SC_MINIMIZE 

SC_MAXIMIZE 

SC_NEXTWIND0W 

SC_PREVWINDOW 

SC_CL0SE 

SC_VSCR0LL 

SC_HSCROLL 

SC_MOUSEMENU 

SC_KEYMENU 


OxFOOO, 
OxFOlO, 
0xF020 , 
0xF030 , 
0xF040 , 
0xF050 , 
0xF060, 
0xF070 , 
0xF080 , 
0xF090 , 
OxFIOO , 


all 


types of system 
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SC_ARRANGE 

SC_RESTORE 

SC_TASKLIST 


OxFllO , 
0xF120 , 
OxFIBO , 
0xF140 , 
0xF150 , 
0xF160, 
0xF170 , 
0xF180 , 
OxFOOF 


SC_SCREENSAVE 


SC_HOTKEY 

SC_DEFAULT 


SC_MONITORPOWER = 
SC_CONTEXTHELP = 
SC_SEPARATOR 


private void btnTest_Cl i ck(object sender, System. EventArgs e) 


// Minimize all of the windows. 
PostMessage(HWND_BROADCAST, 


WM_SYSCOMMAND , 

(IntB2)SystemCommand . SC_RESTORE, 

0 ); 


As you can see, using PostMessageO with the broadcast handle is essentially the same as 
using SendMessageO — the main difference is that the function returns immediately. If you 
try using this code with SendMessageO in place of PostMessageO, you’ll see a definite delay 
as SendMessageO waits for all of the windows to return a response. 

This code has an interesting side effect. Not only does it restore all of the visible windows, 
but it restores all of the hidden windows as well. The resulting chaos might look unappealing, 
but I’ve actually learned about a few windows that don’t appear in the Spy++ list, but do appear 
on screen after using this call. Log off and back on your machine to restore the screen — a 
reboot isn’t necessary to hide the hidden windows again. 

A second special handle accesses the Desktop. The HWND_DESKTOP handle enables you to send 
messages to the Desktop using either PostMessageO or SendMessageO. Here’s the definition 
for HWND _DESKT0P. 

// The HWND_DESKTOP handle sends message only to the Desktop, 
public IntPtr FIWND_DESKTOP = new IntPtr(O); 

The AddFontFi 1 e() method replicates the functionality of the AddFontResourceO function 
of the Win32 API. Both enable you to add private fonts to your application without registering 
them within Windows first. Either form of the function works fine if you want to share your 
registered font with every other application running in Windows. However, what happens if 
you want to keep your special font truly secret? You need to use the AddFontResourceExO 
function. This Win32 API function includes flags that keep your font secret and prevent other 
applications from enumerating the font. However, no matter which function you use to load 
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NOTE 


a font, you still have to tell everyone that there was a change to the font table, which means 
sending a message. The code in Listing 4.2 shows how to load the Vi sual UI .TTF font that 
appears on most hard drives with Visual Studio .NET (among other applications) installed. 


For best viewing results, run this example application outside of the debugger. If you load 
the font while within the debugger, it tends to stay in memory until you exit the Visual 
Studio IDE. You can still follow code execution within the debugger to see how the various 
calls work — the only problem is that the font won’t unload. That’s because Windows asso- 
ciates the font with the Visual Studio IDE instead of the application since the application 
is executing within the debugger environment. 


Listing 4.2 Use the AddFontFileEx() Function to Load Fonts Privately. 

// The function required to add a private font resource. 

[D1 f Import ( "GDI32 . DLL" )] 

public static extern int AddFontResourceEx(Stri ng 1 pszFi 1 ename , 

Int32 fl, 

IntPtr pdv) ; 

// The function required to remove a private font resource. 

[D1 1 Import ( "GDI32 . DLL" )] 

public static extern bool RemoveFontResourceEx(Stri ng IpszFilename, 

Int32 fl , 

IntPtr pdv); 

// Flags used to define how the private font resource is loaded, 
public const Int32 FR_PRIVATE = 0x10; 

public const Int32 FR_N0T_ENUM = 0x20; 

// Used to send a system command message. 

[D1 1 Import ( " User32 . DLL" )] 

public static extern int PostMessage(IntPtr hWnd, 

UInt32 Msg, 

Int32 wParam, 

Int32 IParam); 

// The WM_SYSC0MMAND constant used to access the SC constants, 
public const Int32 WM_F0NTCHANGE = OxOOlD; 

// The HWND_BROADCAST handle sends the message to all windows, 
public IntPtr HWND_BROADCAST = new IntPtr(OxFFFF) ; 

System. Drawi ng .Text . Pri vateFontCol 1 ecti on PFC ; 

private void btnLoadFont_Cl i ckfobject sender, System. EventArgs e) 

1 

// Determine which action to take. 
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if (btnLoadFont.Text == “Load Font") 

{ 

int Result = 0; // Results of loading the font. 

// Load the desired font. 

Result = AddFontResourceEx( 

“D:\\Program Files\\Microsoft Visual Studio 
. NET\\Common7\\IDE\\Vi sual UI .TTF" , 

FR_PRIVATE , 

IntPtr.Zero); 

// Check the results, 
if (Result == 0) 

// Display an error message if necessary. 

MessageBox.Show("The font failed to load for some reason.”, 
"Load Failure", 

MessageBoxButtons.OK, 

MessageBoxIcon .Error) ; 

el se 

{ 

// Change the button caption. 
btnLoadFont.Text = "Unload Font"; 

// Tell everyone we've loaded a new font. 
PostMessage(HWND_BROADCAST, WM_F0NTCHANGE, 0, 0); 

} 

} 

el se 

{ 

bool Result; // Results of loading the font. 

// Load the desired font. 

Result = RemoveFontResourceEx( 

"D:\\Program Files\\Microsoft Visual Studio 
. NET\\Common7\\IDE\\Vi sual UI .TTF" , 

FR_PRIVATE , 

IntPtr.Zero) ; 

// Check the results, 
if (IResult) 

// Display an error message if necessary. 

MessageBox.Show("The font failed to unload for some reason.", 
"Unload Failure", 

MessageBoxButtons .OK, 

MessageBoxIcon .Error) ; 

el se 

{ 

// Change the button caption. 
btnLoadFont.Text = "Load Font"; 
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// Tell everyone we've loaded a new font. 
PostMessage(HWND_BROADCAST, WM_FONTCHANGE, 0, 0); 

} 

} 

} 

private void btnDisplayDialog_Click(object sender, System. EventArgs e) 

{ 

// Display the font dialog. 
dlgFont.ShowDialog(this); 


As you can see, the sample code can load and unload the Vi sual UI . TTF font. The AddFont- 
ResourceExO and Remove FontResourceExO function calls load the font publicly if you don’t 
specify any flags or privately if you specify the FR_PRIVATE flag shown. Notice the use of 
PostMessageO in this example. You must tell other windows about the new font or they won’t 
recognize it (this includes other windows in the current application). The WM_FONTCHANGE 
message doesn’t require any parameters — the other windows will create a fresh enumeration 
of the font list if necessary. 

If you click Display Fonts immediately after loading the example application, you’ll notice 
that the VisualUI is missing from the list. Load the font with the code shown in Listing 4.2 
and you’ll see the VisualUI font in the list as shown in Figure 4.6. 


FIGURE 4.6: 

Loading the VisualUI 
font using the default 
code displays it in the 
Font dialog box. 



There are some interesting changes you can make to the code in Listing 4.2 . For example, 
try the example with a SendMessageO in place of a PostMessageO call and you’ll see the time 
differential can be significant. Try running the call without sending the WM_F0NTCHANGE mes- 
sage at all and you’ll notice that not even the local application will notice it in some cases (the 
change becomes intermittent). Try loading the font publicly (without any flags). Other appli- 
cations such as Word will contain the font in their font list. Reboot the machine after a public 
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load to ensure that the font is removed from memory. Now, try using the FR_NOT_ENUM flag 
when loading the font and you’ll notice that only the test application displays the font. 


The AddFontResourceExO function, like many of the special functions in the book, isn’t 
supported by Windows 9x systems, including Windows Me. In addition, the fonts you add 
using this function are only accessible for the current session — they’re unloaded as soon 
as the user reboots the machine. As you can see, it’s essential to check the Platform 
SDK documentation for limitations on using Win32 API functions directly. 

The Vi sual UI .TTF font is interesting for developers, but almost useless for users, so it makes 
a perfect private font. Figure 4.7 shows what this font looks like. As you can see, it contains 
the special font Microsoft uses for drawing the VCR-like controls on screen. It also contains 
some unique graphics such as the pushpin used in some areas of the Visual Studio IDE. Having 
access to these special graphics can save development time. 


FIGURE 4.7: 

The VisualUl font may 
not have much to offer 
users, but it can save 
some drawing time for 
developers. 


Q VisualUl (TrueType) 


BUI® 


VisualUl (TrueType) 


Typeface name: VisualUl 
: ile size: 6 KB 
Version: Version 0.30 

Copyright (c) 2000 Microsoft Corporation. All rights reserved, 
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There are several variations on the PostMessageO function. One of the more interesting 
messages is PostThreadMessageO. This form of the function enables you to post a message 
to the threads of the current application. You still provide Msg, IParam, and wParam arguments, 
However, instead of a window handle, you need to provide a thread identifier. The Post- 
ThreadMessageO function has several constraints, including a special constraint under Win- 
dows 2000 and Windows XP — the thread identifier must belong to the same desktop as the 
calling thread or to a process with the same Locally Unique Identifier (LUID). 
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You’ll almost never need to use the PostQui tMessageO function. All .NET languages have 
a built-in method to perform this task and you’re better off using it whenever possible. The 
PostQui tMessageO tells Windows that your application is going to exit. It includes an exit 
code that an external application can use to determine the exit status of your application (gen- 
erally 0 for a successful exit). It’s important to know about this function because it does come 
in handy in certain rare circumstances — mainly within wrapper DLLs. You can use this mes- 
sage to force an application exit when catastrophic events occur. The only time you should 
consider using this message is if the application is hopelessly frozen and you still want to pro- 
vide some means of exit (so the user doesn’t have to perform the task manually). In short, for 
the .NET developer, this is the message of last resort. 

SendNotifyMessageO 

Sometimes you need a message whose behavior depends on the circumstance in which it’s 
used. The SendNotifyMessageO function combines aspects of the SendMessageO and the 
Pos tMessageO functions we discussed earlier. When you use SendNoti fyMessageO to send a 
message to the window process in the same thread, it waits for a response. On the other hand, 
if you send the message to a window in another thread, SendNoti fyMessageO returns immedi- 
ately. This duality of function ensures you gain reliable message transfer for the local thread, 
without the performance delay of waiting for other threads to complete their work. 

WARNING Avoid using pointers in any asynchronous message function, including SendNotify- 
MessageO, PostMessageO, SendMessageCal 1 back(), because the function will likely 
fail. The message call will return before the recipient can look at the data pointed at 
by the pointer, which means the recipient may not have access to the data required to 
complete the call. For example, the caller could deallocate the memory used by the data 
immediately upon return from the call. If you need to send a pointer as part of a message, 
then use the SendMessageO function to ensure the recipient is done using the pointer 
before the message returns. While this technique does incur a performance penalty, it also 
ensures that the message will complete as anticipated. 

The SendNoti fyMessageO function requires the same input as both SendMessageO and 
PostMessageO. You can use it to send both single-window and broadcast messages. 

SendMessageCallback() 

The SendMessageCal 1 back() function has two main purposes. First, it sends a message to 
another process — just like the other message-related functions we’ve discussed so far. Second, 
it registers a callback function with the message recipient. A callback function is a special 
function used by the message recipient to return message results to the message sender. In 
short, this is the first function to provide a two-way communication path for messages. 
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The first four arguments for the SendMessageCal 1 back() function are the same as any other 
message function. You need to provide an hWnd, msg, IParam, and wParam values. The fifth 
argument, 1 pCa 11 Back, is a. pointer to a callback function. This requirement means you need 
to use a delegate to pass the address pointer. We’ll see how this works in Chapter 5, which 
concentrates on callback functions. The sixth argument, dwData, is a value that you can pass 
from your application, through the message recipient, and back to the callback function. This 
application-defined value can provide input to the callback function that determines how it 
processes the message return data. 

You’ll normally use the SendMessageCal 1 backQ function to retrieve data from a device, 
system service, or other data source that the .NET framework doesn’t support directly. For 
example, you could use this technique to obtain an enumeration of the devices located on a USB. 

GetMessage() and PeekMessage() 

We’ve discussed the Windows message pump and several of the messages that can appear 
within the message queue. You know that whenever an application sends a message, Windows 
will place the message in the recipient’s message queue, which is essentially an “In Box” for 
Windows messages. However, we haven’t discussed how the recipient actually receives the 
message so it can act on it. The GetMessageO and the PeekMessageO functions provide the 
means for retrieving a message from the Windows message queue so the application can act 
on it. Use the GetMessageO function to remove the message from the queue and the 
PeekMessageO function to see if the message exists without removing it. 

In most cases, you’ll never need to use the GetMessageO or the PeekMessageO functions 
because CLR handles these requirements for you. However, these functions do come in handy 
for special messages (see the Regi sterWi ndowMessageO section that follows) or within wrapper 
DLLs. What’s most important is to understand the mechanism used to retrieve the messages 
once they arrive in the queue. 

The GetMessageO function requires four inputs. The lpMsg argument is the most important 
because it contains a pointer to the Msg data structure used to hold the message information. 
When the call returns, the Msg data structure contains the information needed to process the 
message. The hWnd argument contains a handle to a window. However, you can set hWnd to nul 1 
if you want to retrieve a given message for all windows associated with the current process. The 
wMsgFi 1 terMi n and wMsgFi 1 terMax arguments contain a range of messages that you want to 
retrieve based on the value for each message (see the C header files for a complete list — the 
various examples in the chapter have already shown you the values of specific messages). If 
you want to retrieve a single message, then you set the wMsgFi 1 terMi n and wMsgFi 1 terMax 
arguments to the same value. There are also predefined ranges values such as WM_MOUSEFIRST 
and WM_MOUSELAST that obtain specific input values. 
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The PeekMessageO function requires all of the arguments used by the GetMessageO 
function. You also need to provide a wRemoveMsg argument value. A value of PM_REM0VE will 
remove the message from the queue, while a value of PM_NOREMOVE will keep the message on 
the queue. Given the reason for using PeekMessageO, you’ll probably use PM_NOREMOVE 
in most cases. 

RegisterWindowMessageO 

You’d think that with all of the messages that Windows supports natively, you’d never need 
to create a message of your own. Actually, applications commonly create custom messages for 
intra-application communication. Sometimes an application will spawn other processes and 
need to communicate with those processes using a special set of messages. Because the mes- 
sages are sent publicly with SendMessageO or PostMessageO, Windows needs to know about 
them and you need to provide a unique name for them. The purpose of the Regi sterWi ndow- 
MessageO function is to register a unique name for your custom message. All you need to 
supply is a string containing the message name. 

Creating a Windows Message Handler Example 

This chapter already contains several examples that show how to send a message to Windows. 
Given an application need, you can send a request to Windows to answer that need. In fact, 
you can affect the operation of all of the applications running under Windows in some cir- 
cumstances (as was shown with the MinimizeAll example). However, there are times when 
you want to create an environment where Windows can send a message to your application. 
Of course, this already happens all the time when users click buttons and enter text, but you 
might have some special message that you want Windows to send to your application that the 
.NET Framework doesn’t handle by default. 

The example in this section shows how to create a message handler that will react when 
Windows sends a specific message. To do this, we have to override the default .NET function- 
ality for the Windows message pump, create an event that the message pump will fire when 
it receives the message in question, and create an event handler that does something when it 
receives an event notification. The following example is a prototype of sorts for handling all 
kinds of Windows messages. You’ll see more advanced examples of this technique in Chapter 9 
when we tackle advanced Windows XP features such as Fast User Switching. You’ll find the 
code for this example in the \Chapter 04\C#\ReceiveMessage and \Chapter 04\VB\Receive- 
Message folders of the CD. 
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Creating the Event 

The event portion of the code generates an event when requested. It will send the event to 
any number of handlers — all of which must register to receive the event notification. The 
event portion of the code doesn’t do anything with the event notification; it merely reacts to 
the event and generates the notification. This is an extremely important distinction to con- 
sider. Listing 4.3 shows the event code for this example. 

Listing 4.3 The Event Code for a Message Handler 

// Create an event for the message handler to fire. We also 
// have to handle this event or nothing will happen, 
public delegate void DoSDCheck(object sender, System. EventArgs e); 
public static event DoSDCheck ThisSDCheck; 

// Provide a means for firing the event. 

public static void Fi re_Thi sSDCheck(object sender, System. EventArgs e) 

{ 

// If there is an event handler, call it. 
if (ThisSDCheck != null) 

Thi sSDCheck(sender , e); 

1 


As you can see, you need a delegate to define the appearance of the event handler. DoSD- 
CheckO isn’t an event handler; it merely acts as a prototype for the event handler. The event 
is an instance of the delegate. You must make the event static or no one will be able to call it. 

Once you have an event defined, you need a way to fire it. Microsoft doesn’t define the name 
of the method for firing an event in any concrete terms, but standard practice is to preface the 
event name with the word “Fire” followed by an underscore, so the name of this method is 
Fi re_Thi sSDCheck( ). Firing an event can require a lot of work; but generally all you need to do 
is verily that the event has at least one handler, and then call the event. This step will call every 
assigned event handler in turn to process the event notification. 

Creating the Windows Message Loop Override 

The most important tip you can remember about processing messages is that the .NET Frame- 
work will only handle the messages that applications commonly use. If you need any other 
functionality in your application, then you need to add it. Common functionality includes 
messages associated with the mouse and the keyboard — it doesn’t include messages associ- 
ated with a shutdown. 
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Sometimes the Platform SDK documentation is simply wrong. For instance, the documen- 
tation for the WM_QUERYENDSESSION message used in this example tells you that it’s sent 
in response to an Exi tWi ndows() function call. Unfortunately, Windows XP doesn’t sup- 
port the ExitWi ndows() function, so there’s no hope of making this function work properly 
given the documentation. You need to use the Exi tWi ndowsExO function instead. The 
best way to find this information is to use the Dependency Walker to view User32.DLL and 
see if it supports the ExitWindowsO function. The answer becomes obvious during the 
few seconds it takes to check the DLL. 

With this in mind, you have to rewrite the message pump to do something with the mes- 
sages that you want to handle. This means overriding the default message pump, and then 
calling the base message pump to handle any messages that your code doesn’t handle. The 
two-step process is important. If you don’t call the base function, then any messages your 
code doesn’t handle will go unanswered. Of course, you can always use this technique to 
force an application to handle just a few messages and ignore everything else — a somewhat 
dangerous proposition unless you know exactly what you’re doing. Listing 4.4 shows the 
message pump override required for this example. 


Listing 4.4 Always Override the Message Pump to Handle Custom Messages 

// We need to know which message to monitor, 
public const Int32 WM_QUERYENDSESSION = 0x0011; 
public const Int32 WM_ENDSESSI0N = 0x0016; 

protected override void WndProcfref Message ThisMsg) 

{ 

// See which message Windows has passed, 
if ((ThisMsg. Msg == WM_QUERYENDSESSION) || 

(ThisMsg. Msg == WM_ENDSESSION)) 

{ 

// Fire the event. 

Fi re_Thi sSDCheck(thi s , null); 

// No more processing needed, 
return ; 

1 

// If this isn't a session end message, then pass the 
// data onto the base WndProcO method. You must do this 
// or your application won't do anything, 
base .WndProc(ref ThisMsg); 
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The code for the message pump is relatively straightforward. All you need to do is check for 
the session ending messages, and then fire the event. Notice that we return from this function 
without providing a positive response to Windows. This omission enables the application to 
cancel the shutdown. If you want to allow the system to shut down, you must set the Thi sMsg 
.Result value to true. 

Creating the Event Handler 

The event handler for this example doesn’t do much — it displays a message box saying it 
received a notification. However, it’s important to realize that the message handler could do 
anything within reason. Windows sets a time limit for responding to a shutdown message. If 
your event handler is code heavy, your application won’t respond in time and Windows will 
try to shut it down manually. Listing 4.5 shows the event handler for this example. 

Listing 4.5 The Event Handler for the Example is Simple and Fast 

public frmMain() 

1 

// Required for Windows Form Designer support 
InitializeComponentO ; 

// Add an event handler for the shutdown check. 

ThisSDCheck += new DoSDCheck(OnShutDownCheck) ; 

1 

// Create an event handler for the shutdown event. 

private void OnShutDownCheckfobject sender, System. EventArgs e) 

1 

// Display a message showing that we received the message. 

MessageBox.Show( "Windows sent an end session message", 

"End Session Message 1 ', 

MessageBoxButtons .OK, 

MessageBoxIcon . Informati on) ; 

1 


Notice that you must register the event handler. Otherwise, it won’t receive event notifica- 
tions. In this case, the example registers the event handler in the constructor, which is a good 
place for the registration for most applications. If an event handler is important enough to 
monitor messages from Windows, you’ll want to register it during the application startup 
process. 

Demonstrating the Windows Message Handler 

In older versions of Windows you simply told the operating system that you wanted to shut 
down, and that was the end of the process. Newer versions of Windows require a little more 
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information and Windows XP makes it downright impossible to shut down unless you have 
a good reason. For this reason, the code for initiating a Windows shutdown is a bit long. 
Listing 4.6 provides you with the essentials. 


Listing 4.6 Using the ExitWindowsEx() Function to Shut Windows Down 

// Used to send a message that starts the screen saver. 

[D1 1 Import ( " User32 . DLL" )] 

public static extern int Exi tWi ndowsEx(UInt32 uFlags, 

UInt32 dwReason); 


// A list of flags that determine how the system is shut down, 
public enum ShutdownFlag 


EWX_L0G0FF 

EWX_SHUTDOWN 

EWX_REB00T 

EWX_F0RCE 

EWX_P0WER0FF 

EWX_FORCEIFHUNG 


= 0 , 

= 0x00000001, 
= 0x00000002, 
= 0x00000004, 
= 0x00000008, 
= 0x00000010 


} 


// A list of major reasons to shut the system down, 
public enum ReasonMajor 


SHTDN_REAS0N_MA]0R_0THER 
SHTDN_REAS0N_MA10R_N0NE 
SHTDN_REAS0N_MA1 0R_HARDWARE 
SHTDN_REAS0N_MA10R_0PERATINGSYSTEM 
SHTDN_REAS0N_MA10R_S0FTWARE 
SHTDN_REAS0N_MA10R_APPLICATI0N 
SHTDN_REAS0N_MA1 0R_SYSTEM 
SHTDN_REAS0N_MA10R_P0WER 


= 0x00000000, 
= 0x00000000, 
= 0x00010000, 
= 0x00020000, 
= 0x00030000 , 
= 0x00040000, 
= 0x00050000, 
= 0x00060000 


1 


// A list of minor reasons to shut the system down. Combine 
// these reasons with the major reasons to provide better 
// information to the system, 
public enum ReasonMinor 


SHTDN_REAS0N_MIN0R_0THER 

SHTDN_REAS0N_MIN0R_N0NE 

SHTDN_REASON_MINOR_MAINTENANCE 

SHTDN_REAS0N_MIN0R_INSTALLATI0N 

SHTDN_REAS0N_MIN0R_UPGRADE 

SHTDN_REAS0N_MIN0R_REC0NFIG 

SHTDN_REAS0N_MIN0R_HUNG 

SHTDN_REAS0N_MIN0R_UNSTABLE 

SHTDN_REAS0N_MIN0R_DISK 

SHTDN_REAS0N_MIN0R_PR0CESS0R 


0x00000000, 
OxOOOOOOff, 
0x00000001, 
0x00000002 , 
0x00000003, 
0x00000004, 
0x00000005, 
0x00000006, 
0x00000007, 
0x00000008, 
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SHTDN_REASON_MINOR_NETWORKCARD 

SHTDN_REASON_MINOR_POWER_SUPPLY 

SHTDN_REASON_MINOR_CORDUNPLUGGED 

SHTDN_REASON_MINOR_ENVIRONMENT 

SHTDN_REASON_MINOR_HARDWARE_DRIVER 

SHTDN_REASON_MINOR_OTHERDRIVER 

SHTDN_REASON_MINOR_BLUESCREEN 

SHTDN_REASON_UNKNOWN 


// A list of reason flags that provide 
// cause of shutdown. Combine these fl 
// values. 

public enum ReasonFlag : uint 

{ 

SHTDN_REASON_FLAG_USER_DEFINED 

SHTDN_REASON_FLAG_PLANNED 

} 


= 0x00000009, 

= 0x0000000a, 

= 0x0000000b, 

= 0x0000000c, 

= OxOOOOOOOd, 

= OxOOOOOOOe, 

= OxOOOOOOOF, 

= SHTDN_REASON_MINOR_NONE 


additional information about the 
.gs with the major and minor reason 


= 0x40000000, 
= 0x80000000 


private void btnTest_Cl i ck(object sender, System. EventArgs e) 

{ 

// Exit Windows. 

ExitWi ndows Ex( (Uint 32) Shutdown Fl ag . EWX_LOGOFF, 

(UInt32)ReasonMajor . SHTDN_REAS0N_MA30R_APPLICATI0N & 
(UInt32)ReasonMi nor . SHTDN_REASON_MINOR_MAINTENANCE & 
(Uint 32) Reason Flag . SFITDN_REASON_FLAG_PLANNED) ; 


There are a lot of predefined reasons for shutting the system down and you should choose 
one of them within your application. Generally, you’ll choose the appropriate ShutdownFl ag 
value for the first argument. Notice there are options for logging off, performing a normal 
reboot, and forcing a shutdown for a hung application. This last option should be used with 
care, but it’s a valuable option if an application detects that it has frozen and the system is in 
an unstable state. (Of course, recovering from the condition is even better.) 

I decided to split the second argument into three enumerations because each enumeration 
performs a different task. You should always include a ReasonMajor value as part of the shut- 
down. The ReasonMi nor value further defines the reason for the shutdown, but isn’t essential. 
Finally, you can pass a ReasonFl ag value if one of the values happens to meet your needs. 

Developing for Thread Safety 

You might think that all of the convoluted code in this example could be straightened out and 
made simpler. The fact is that the technique shown in this example becomes more important 
as the complexity of your code increases. The moment you introduce a second thread into the 
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application, the need for all of the convoluted code becomes essential. Using events as we have 
here keeps the message handling in the main thread. 

One of the Visual Studio IDE windows that you need to look at is the Threads window. 
Unfortunately, the Visual Studio IDE hides this window by default and most developers don’t 
find it because it’s hidden on the Debug menu instead of the View menu. To display the Threads 
window, use the Debug >- Windows >- Threads command. Figure 4.8 shows an example of 
the Threads window for the current application. 


FIGURE 4.8: 

The Threads window 
can be helpful in 
diagnosing problems 
with a Win32 API 
message handler. 

Any code that changes the appearance of a Windows Form must execute from the main 
thread of the application. This is why you want to use an event handler for your message 
handling code. Using an event handler means that no matter which thread intercepts the 
message you want to process, the main thread will perform the actual processing. 



Where Do You Go from Here? 

This chapter has demonstrated various uses for Windows messages in managed applications. 
Like unmanaged Windows applications, managed applications use messaging to communicate 
between applications and the operating system. Knowing which Windows messages the .NET 
Framework supports natively can help you determine when you need to create a handler for 
non-standard messages. 

We have discussed the correlation between some .NET Framework event handlers and the 
Win32 API messages. Create a small test application and use Spy++ to verify the messages that 
it responds to. Add objects such as menus to see the effect on the output messages. Remember 
to limit the message selections in Spy++ so that you can actually see the messages of interest — 
some messages (especially those for mouse handling) appear with such regularity that it’s hard 
to see the messages that appear only when specific events occur. 

Make sure you try out all of the examples on the CD. There are places in the chapter where 
I mention an example, but don’t go completely through the code because most of it has 
appeared in other chapters. It’s still important to check the example out because you’ll learn 
techniques for working with messages by using them. Especially important are some of the 
system commands that aren’t handled very well by the .NET Framework. 
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Chapter 4 • Processing Windows Messages 


Now that you know about messages, it’s time to look at the last generic feature for Win32 
API programming — the callback function. Chapter 5 tells you how Windows uses callback 
functions for various tasks and when you’ll need to use them for your Win32 API call. Call- 
back functions are important because they provide a mechanism for Windows to interact with 
an application. Essentially, the application makes a request and Windows answers it through 
the callback function. This asynchronous handling of application requests enables Windows 
to run more efficiently, but does add to the developer’s workload. 
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